oneM2M Architecture
The oneM2M standard (as provided in oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0, which is incorporated by reference in its entirety) under development defines a Service Layer called “Common Service Entity (CSE).” FIG. 1 illustrates an exemplary oneM2M architecture that defines a service layer. The Service Layer provides “horizontal” services that can be utilized by different “vertical” machine-to-machine (M2M) systems and applications, such as e-Health, fleet management, and smart homes. Mca reference point 111 interfaces with application entity (AE) 112. Mcc reference point 113 interfaces with another CSE 115 within the same service provider domain and Mcc′ reference point 116 interfaces with another CSE (not shown) in a different service provider domain 117. Mcn reference point 118 interfaces with the underlying network service entity (NSE) 119. NSE 119 provides underlying network services to the CSEs, such as device management, location services and device triggering. CSE contains multiple logical functions called “Common Service Functions (CSFs)”, such as “Discovery” or “Data Management & Repository.”
Within the oneM2M RESTful architecture, (also known as resource oriented Architecture or RoA) the CSE supports the instantiation of a set of common service functions (CSFs), as shown in FIG. 2. CSF functionality is implemented via resources which are uniquely addressable entities having a representation that can be manipulated via RESTful methods such as Create, Retrieve, Update, and Delete. These resources are addressable using universal resource identifiers (URIs). A resource supports a set of attributes that store relevant information about the resource and may contain references to other resources termed child resources(s). A child resource is a resource that has a containment relationship with a parent resource and whose lifetime is limited by the resource lifetime of the parent.
From a deployment perspective, FIG. 3 depicts configurations supported by the oneM2M architecture. oneM2M architecture enables the application service node (ASN), application dedicated node (ADN), the middle node (MN), and the infrastructure node (IN). The ASN is a node that contains one CSE and contains at least one AE. An example of physical mapping is an ASN residing in an M2M Device. The ADN is a node that contains at least one AE and does not contain a CSE. An example of physical mapping is an ADN residing in a constrained M2M Device. An MN is a node that contains one CSE and contains zero or more AEs. An example of physical mapping for an MN is an MN residing in an M2M Gateway. The IN is a node that contains one CSE and contains zero or more AEs. An example of physical mapping for an IN is the IN residing in an M2M Service Infrastructure. There also may be a non-oneM2M node, which is a node that does not contain oneM2M Entities (neither AEs nor CSEs). Such nodes represent devices attached to the oneM2M system for interworking purposes, including management.
Registration
Conventionally, an AE on an ASN, an MN, or an IN performs registration locally with the corresponding CSE in order to use M2M services offered by that CSE. An AE on an ADN performs registration with the CSE on an MN or an IN in order to use M2M services offered by that CSE. An IN-AE performs registration with the corresponding CSE on an IN in order to use M2M services offered by that IN CSE.
The CSE on an ASN performs registration with the CSE in the MN in order to be able to use M2M services offered by the CSE in the MN. As a result of successful ASN-CSE registration with the MN-CSE, the CSEs on the ASN and the MN establish a relationship allowing them to exchange information.
The CSE on an MN performs registration with the CSE of another MN in order to be able to use M2M Services offered by the CSE in the other MN. As a result of successful MN-CSE registration with the other MN-CSE, the CSEs on the MNs establish a relationship allowing them to exchange information.
The CSE on an ASN or on an MN perform registration with the CSE in the IN in order to be able to use M2M Services offered by the CSE in the IN. As a result of successful ASN/MN registration with the IN-CSE, the CSEs on ASN/MN and IN establish a relationship allowing them to exchange information.
In the above described cases, the AE or CSE performing the registration is referred to as a Registree AE or Registree CSE. The CSE on which the AE or CSE is registering is referred to as the Registrar CSE.
Following a successful registration of an AE to a CSE, the AE is able to access, assuming access privilege is granted, the resources in all the CSEs that are potential targets of request from the Registrar CSE.
The followings are some conventional registration regulations:                An AE shall not be registered to more than one CSE (ASN-CSE, MN-CSE or IN-CSE).        An ASN-CSE shall be able to be registered to at most one other CSE (MN-CSE or IN-CSE).        An MN-CSE shall be able to be registered to at most one other CSE (MN-CSE or IN-CSE).        A concatenation (registration chain) of multiple uni-directional registrations shall not form a loop. E.g. two MN-CSEs A and B, cannot register with each other. Three MN-CSEs A, B and C, where A registers to B, and B registers to C, then C cannot register to A.        
Conventionally the CSE registration procedure requires the creation of two resources (a <remoteCSE> on the Receiver CSE and a <remoteCSE> on the Originator CSE). The Originator shall be the registree CSE. The Receiver shall be the registrar CSE creating the <remoteCSE> resource initially. FIG. 4 illustrates an exemplary procedure for creating a <remoteCSE> resource. At step 131, originator 121 sends the CREATE Request message. At step 132, receiver 121 processes the registration request message. At step 133, receiver 121 responds with a registration response message that contains the address/URI of the registered CSE. At step 134, originator, upon receipt of the CREATE response message, creates a <remoteCSE> resource locally under its <CSEBase> resource. This resource is representing receiver 121 CSE. Originator 120 provides the appropriate values to all mandatory parameters. At step 135, originator 120 may issue a RETRIEVE Request towards the receiver (same To as for the CREATE request message) to obtain the optional parameters of the <remoteCSE> resource created at receiver 121 as for step 134 (e.g. labels, accessControlPolicyIDs attributes). At step 136, receiver 121 verifies that originator 120 has the appropriate privileges to access the information. At step 137, receiver 121 sends a RETRIEVE response message. At step 138, originator 120 updates the created <remoteCSE> resource for receiver 121 with the information obtained in step 137.
Conventionally, the procedure for AE registration follows the message flow description as depicted in FIG. 5. The Originator is the Registree AE. The receiver (Registrar CSE) allows the creation of the <AE> resource according to the access control policy and information in the applicable subscription profile. The receiver derives the applicable M2M-Service-Profile-ID from the CSE-ID of the Registrar CSE. Note that in FIG. 5, some of the information has been truncated, but may be found in oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0.
With reference to FIG. 5, at step 141, if the Registree AE 123 intends to use a security association to perform the registration, a security association establishment procedure is carried out first. At step 142, Registree AE 123 sends the information for the registration CREATE procedure with the following specific information in the CREATE Request message:
From: AE-ID-Stem or NULL.                In case the Registree AE 123 has already registered successfully before, then deregistered and intends to register again with the same AE-ID-Stem value as before, the Registree AE 123 shall include that AE-ID-Stem value into the From parameter.        In case the Registree AE 123 has not registered successfully before and intends to get an M2M-SP-assigned AE-ID-Stem starting with an ‘S’ character assigned to itself but it does not have any specific value to suggest, it shall set the From parameter to the character ‘S’.        In case the Registree AE 123 intends to initiate a fresh registration and has no preference for the AE-ID-Stem value, the From parameter shall be set to NULL.At step 143, the Receiver (e.g., Registrar CSE 124) shall determine whether the request to register the Registree AE 123 meets any of the following conditions. There is a check if the applicable service subscription profile lists a combination of (allowed AE-ID-Stem value and allowed App-ID value) for the Credential-ID and the Registrar CSE-ID that match with the App-ID attribute in the Content parameter of the request and the AE-ID-Stem in the From parameter of the request. The applicable rules for this checking are contained in the <serviceSubscribedAppRule> resource(s) which are linked to by the ruleLinks attribute of the <m2mServiceSubscribedNode> resource(s) associated with the Registrar CSE. At step 144, if the From parameter of the request provides an AE-ID-Stem value, the Registrar CSE checks whether an <AE> resource with an Unstructured-CSE-relative-Resource-ID identical to the AE-ID-Stem value provided in the From parameter of the request does already exist. If so, there is still an active registration using the same AE-ID-Stem on the Registrar CSE and the Registrar CSE shall respond with an error.        
With continued reference to FIG. 5, the procedure continues with one for the following cases a)-d), details can be found in oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0, which all end in a response of step 149:                Case a) AE-ID-Stem starts with ‘S’ and AE does not include an AE-ID-Stem (initial registration)—Steps 145a through 148a.         Case b) AE-ID-Stem starts with ‘S’ and AE includes an AE-ID-Stem (re-registration)—Steps 145b through 148b         Case c) AE-ID-Stem starts with ‘C’ and AE does not include an AE-ID-Stem (initial registration)—Step 145c         Case d) AE-ID-Stem starts with ‘C’ and AE includes an AE-ID-Stem (re-registration)—Step 145d Resource Type m2mServiceSubscriptionProfile        
Conventionally, the <m2mServiceSubscriptionProfile> resource represents an M2M Service Subscription. It is used to represent all data pertaining to the M2M Service Subscription, i.e. the technical part of the contract between an M2M Application Service Provider and an M2M Service Provider. The serviceRoles attribute of the <m2mServiceSubscriptionProfile> resource contains a list of Service Role IDs (S-RoleID) that are subscribed to in this service subscription.
Service Orchestration Profile
Conventionally, the role of Service Orchestration Profiles is to provide a mechanism for the exchange of service related attributes (i.e. metadata) that can be used for service orchestration as well as other functions such as service discovery. The following attributes are some examples of the Service Orchestration Profile. A profile identifier specifies an identifier of a profile. Profile Semantics specifies a semantic description or an address/link to a semantic description that describes service orchestration attributes contained within the profile. Profile Type specifies the type of profile. Service Orchestration Targets specifies an optional list of targets that service orchestration is to be performed upon (e.g. a service nodes, service layer, or service capability instance). Service Orchestration Schedule specifies scheduling information for when service orchestration is to be performed and/or duration of time for which profile is valid. Service Orchestration Policies specifies policies to qualify performing service orchestration. Service Orchestration Context specifies context information that is applicable to service orchestration. Desired Services specifies the service configuration that an orchestration client is requesting to be orchestrated onto a specified target(s). Supported Services specifies the set of supported services that an orchestration target supports.
Service Layer Message Routing Service
The Message Routing Service is a service that allows a CSE to route and forward messages from its registree AE or CSE (the message may originate from the registree AE or CSE, or the message may be forwarded by the registree CSE) to the target. In general, the Message Routing Service is a service that a registrar entity may provide to a registree entity, and vice versa. The Message Routing Service may be considered as a special service, because by default, the Message Routing Service is mutual and bidirectional. It means that when a registrar entity grants access permission of this Message Routing Service to its registree entity, the registree entity automatically provides the Message Routing Service for the registrar entity as well. Note, this is the default setting of the Message Routing Service, however, the service can be set up as uni-directional. Each of the local services hosted by a SL entity shall have an identifier that is unique among all local services.